CASE Validation Results

Summary

Details

Validation Report
Conforms: True

Validation Report

Conforms: True

Validation Report

Conforms: True

My review boils down to a matter of maintenance opinion.

I believe, personally, that the feature introduced in this pull request is harmful, via application of the Robustness Principal: "Be conservative in what you send, and liberal in what you accept". I am, again personally, a subscriber to the spirit of RFC 9413:

Time and experience show that negative consequences to interoperability accumulate over time if implementations silently accept faulty input.

This PR introduces a feature that says it is permissible to a user to ignore warnings in specifically the IRIs in data professing to be a part of a CDO ontology or CDO-adopted ontology.

For better or worse, case-utils currently offers no such specific support. Warnings of undefined CDO IRIs are treated with the same severity as sh:Warning-severity constraint violations from SHACL validation reports: If the data is validated with case_validate --allow-warnings, all warnings are accepted(/excepted). So, in implementation, the feature in this PR has an effect that is incongruous with its keywording.

I am not personally happy with the idea of putting effort into supporting such a split in warning categories. If a graph has a typo'd IRI, I believe it should be fixed in the generating application. If a graph tried using a new custom concept under a CDO namespace, I believe it should go into some drafting namespace, rather than attempt to search CDO resources for a concept definition that it won't find, or induce pain on downstream data adopters when they can't integrate data from that faulty generator.

For the moment, I am a NACK on this PR because of the effect-scope incongruity. I'm more comfortable with this PR adding an option to expose allow_warnings via call-environment configuration. That and allow_infos are features that case-utils forwards from pyshacl, and pyshacl implements those from design induced by sh:severity, so SHACL already opened the "Here's how to ignore warnings" door. I'm not comfortable introducing a new subtle way to have faulty data.